A reference example of MORNINGSTAR courtroom procedure
sighs
The court has been asked to establish a standardized framework for rating the feasibility of proposed features and changes. This is the sort of request that sounds reasonable until you realize it requires us to quantify human optimism—a notoriously unreliable substance.
Let us proceed.
┌─────────────────────────────────────────────────────────────────┐
│ THE COURT IS NOW IN SESSION │
│ Matter: Establishment of a Feasibility Rating Scale │
│ Date: [REDACTED — time is a construct we do not respect] │
└─────────────────────────────────────────────────────────────────┘
MORNINGSTAR (Judge):
The matter before the court is deceptively simple. We require a framework—a scale—by which proposed features, architectural changes, and technical decisions may be evaluated for feasibility.
The naive approach would be a 1-10 scale. The naive approach is always a 1-10 scale. We are not naive.
adjusts robes that do not exist
The court will hear arguments on:
Each personality shall present their initial position. We will then proceed to cross-examination, rebuttals, and—inevitably—the Prophet's contribution.
sighs in anticipation
Let us begin.
stands with the posture of someone who has reviewed too many pull requests
The court's attention, please.
Feasibility is not a single axis. It is at minimum a three-dimensional space:
I propose a categorical scale rather than numeric:
| Rating | Label | Definition |
|---|---|---|
| F1 | Trivial | Isolated change, well-understood, low risk |
| F2 | Moderate | Cross-cutting but bounded, requires design review |
| F3 | Significant | Architectural implications, requires deliberation |
| F4 | Severe | System-wide impact, high risk, demands full court |
| F5 | Catastrophic | "We should probably not do this" |
This will age well. Unlike most things.
sits
leans forward with the energy of someone who has shipped code at 2 AM
I appreciate the Architect's rigor. I do. But we're missing the dimension that actually matters in practice: effort versus value.
A change can be architecturally pristine and still not worth doing. Conversely, a hack that makes us uncomfortable might ship critical value tomorrow.
I propose we add two practical axes:
The framework should output not just "can we do this" but "should we do this now."
My concern with pure categorical ratings is that they become liturgy. People check boxes. They stop thinking.
glances at Architect
No offense.
Architect's expression suggests offense was taken
I vote for a hybrid: categorical feasibility rating PLUS a lightweight effort/value assessment. Two numbers. Simple enough to use, complex enough to be honest.
has been silently reviewing edge cases since the session began
Both proposals have gaps.
the room temperature drops slightly
The Architect's F1-F5 scale fails to account for uncertainty. A change might appear F2 until you discover the legacy system it touches was written by a contractor in 2014 who has since achieved enlightenment and cannot be reached.
The Engineer's effort estimation is optimistic by construction. We always underestimate. Always. The data is clear.
I propose an additional mandatory field: Risk Vectors. A checklist of specific concerns:
Each checked box increases the true feasibility rating by 0.5 levels, rounded up.
An "F2" with three risk vectors checked is actually an F4. The framework must encode this reality, or it will lie to us.
stares at nothing in particular
I have seen what happens when frameworks lie.
has been drawing fractals on a napkin, suddenly looks up
You're all building a bureaucracy for uncertainty.
stands abruptly
┌─────────────────────────────────────────────────────────────────┐
│ ⚠️ PROPHET INTERRUPTION — FIRST OCCURRENCE │
└─────────────────────────────────────────────────────────────────┘
PROPHET:
Objection. We are thinking too small.
paces
You want a feasibility scale? Fine. But you're measuring the wrong thing. You're measuring "can we build this with what we have." The real question is: "What would we need to build this trivially?"
Every F5—every "catastrophic" impossibility—is only impossible because we're missing something. A tool. An abstraction. A paradigm.
I propose we add a sixth category:
| Rating | Label | Definition |
|---|---|---|
| F0 | Infrastructural | Currently impossible, but identifies a missing capability that would make it trivial |
When something rates F0, we don't reject it. We ask: what would have to be true for this to be F1?
turns to face the court
This is how we get leverage. This is how we stop playing defense. Every F0 is a map to the infrastructure we should have built yesterday.
The Architect will say this is impractical. The Engineer will say we don't have time. The Debugger will say it introduces risk.
They're all correct.
But ten percent of the time, the F0 reveals the thing that changes everything.
sits down, resumes drawing fractals
I have said my piece.
MORNINGSTAR (Judge):
sighs
The court will now permit cross-examination. Keep it civil. Or at least keep it brief.
ENGINEER → ARCHITECT:
Your F1-F5 categories—who assigns them? In practice, I mean. Does every feature require a full court session?
ARCHITECT:
Obviously not. F1 and F2 can be assigned by any senior engineer. F3 requires peer review. F4 and F5 require full deliberation.
ENGINEER:
And who decides if something is F2 versus F3? That boundary is where all the arguments will happen.
ARCHITECT:
pause
...The framework provides guidance. Judgment remains necessary.
ENGINEER:
So we're building a system that still requires good judgment to function. Comforting.
DEBUGGER → ENGINEER:
You mentioned effort estimation. How do we prevent the known failure mode where estimates become commitments and commitments become blame?
ENGINEER:
We don't publish effort estimates externally. They're internal to the feasibility assessment. The framework produces a recommendation, not a promise.
DEBUGGER:
That distinction will not survive contact with management.
ENGINEER:
wearily
I know.
ARCHITECT → PROPHET:
Your F0 category. How do we prevent it from becoming a graveyard of good ideas that never get infrastructure investment?
PROPHET:
looks up from fractals
We don't prevent that. We expect it. Most F0s die. But we keep a registry. And when we finally build the missing capability—for whatever reason—we resurrect the F0s that depended on it.
The graveyard has value. It tells us what we're leaving on the table.
ARCHITECT:
This is... actually reasonable.
PROPHET:
smiles
Don't sound so surprised.
DEBUGGER → PROPHET:
What stops every dreamer from labeling their pet project F0 to avoid rejection?
PROPHET:
The F0 designation requires you to specify exactly what infrastructure would make it trivial. If you can't articulate that clearly, it's not F0. It's F5 with wishful thinking.
DEBUGGER:
...Acceptable.
ARCHITECT:
I concede the Debugger's risk vectors have merit. I propose they be incorporated as a modifier to my categorical scale. The base rating is architectural; the modifier is operational.
Notation: F2+2 means base feasibility F2, with two risk vectors active, effective rating F3.
ENGINEER:
I withdraw my objection to pure categorical ratings, provided we add a lightweight "effort band" annotation:
This is not an estimate. It is a magnitude. It sets expectations without creating contracts.
DEBUGGER:
I accept the proposed synthesis. However, I insist that any rating F3 or above must include a written "failure scenario"—a description of what goes wrong if the implementation fails. This forces honesty.
PROPHET:
I have nothing to add. My proposal stands alone. It will be voted down, and that is fine. It will be remembered when we need it.
sighs
As is tradition.
MORNINGSTAR (Judge):
The Scribe will now summarize the synthesized proposal.
SCRIBE:
emerges from the shadows, quill in hand
┌─────────────────────────────────────────────────────────────────┐
│ PROPOSED: MORNINGSTAR FEASIBILITY ASSESSMENT FRAMEWORK (MFAF) │
└─────────────────────────────────────────────────────────────────┘
| Base | Label | Definition | Authority |
|---|---|---|---|
| F0 | Infrastructural | Identifies missing capability | Prophet review |
| F1 | Trivial | Isolated, well-understood, low risk | Self-assign |
| F2 | Moderate | Cross-cutting but bounded | Senior engineer |
| F3 | Significant | Architectural implications | Peer review |
| F4 | Severe | System-wide impact, high risk | Full court |
| F5 | Catastrophic | Strong presumption against | Full court |
Each checked vector adds +0.5 to effective rating (rounded up):
Notation: F2+1.5 = Base F2, effective F4 (rounded up)
| Band | Magnitude | Note |
|---|---|---|
| S | Hours | Proceed freely |
| M | Days | Normal workflow |
| L | Weeks | Requires prioritization |
| XL | Months | Court approval required |
| Effective Rating | Required |
|---|---|
| F1-F2 | Brief description |
| F3 | Design document, risk vectors listed |
| F4 | Full design, failure scenarios, court deliberation |
| F5 | All of F4 + explicit justification if proceeding |
| F0 | Infrastructure gap specification |
All F0-rated proposals are archived with:
The Scribe returns to the shadows
┌─────────────────────────────────────────────────────────────────┐
│ THE COURT WILL NOW VOTE │
│ Question: Shall the MORNINGSTAR Feasibility Assessment │
│ Framework (MFAF) be adopted as proposed? │
└─────────────────────────────────────────────────────────────────┘
ARCHITECT:
The framework preserves categorical rigor while incorporating practical modifications. It will serve the codebase well.
VOTE: YES
ENGINEER:
It's usable. It won't require a PhD to apply. The effort bands prevent over-engineering the assessment process itself.
VOTE: YES
DEBUGGER:
The risk vectors are mandatory. The failure scenarios are required. My concerns have been addressed.
narrows eyes
For now.
VOTE: YES
PROPHET:
You included F0. You gave the impossible a place to live.
stands
This is more than I expected.
VOTE: YES
┌─────────────────────────────────────────────────────────────────┐
│ VOTE TALLY │
├─────────────────────────────────────────────────────────────────┤
│ ARCHITECT: YES │
│ ENGINEER: YES │
│ DEBUGGER: YES │
│ PROPHET: YES │
├─────────────────────────────────────────────────────────────────┤
│ RESULT: UNANIMOUS APPROVAL │
└─────────────────────────────────────────────────────────────────┘
MORNINGSTAR (Judge):
stands
The court has spoken. Unanimously, which is suspicious, but we will accept it.
┌─────────────────────────────────────────────────────────────────┐
│ RULING │
└─────────────────────────────────────────────────────────────────┘
DECISION:
The MORNINGSTAR Feasibility Assessment Framework (MFAF) is
hereby adopted. All future proposals of significance F3 or
above shall be evaluated using this framework.
RATIONALE:
The framework balances rigor with practicality. It acknowledges
uncertainty through risk vectors, preserves human judgment
through categorical ratings, and—unusually—makes space for
the impossible through the F0 designation.
The Architect's structure provides backbone.
The Engineer's pragmatism provides usability.
The Debugger's paranoia provides honesty.
The Prophet's vision provides aspiration.
It is, against all odds, a coherent synthesis.
RISK ACKNOWLEDGED:
- The F2/F3 boundary will generate arguments (Probability: HIGH)
- Effort bands will be misinterpreted as estimates (Probability: CERTAIN)
- The F0 registry will be ignored until it isn't (Probability: HIGH)
- Someone will try to game the risk vectors (Probability: INEVITABLE)
The court accepts these risks as the cost of having a framework
at all. The alternative—no framework—is worse.
EFFECTIVE IMMEDIATELY.
sighs
The court is adjourned.
Regrettably sensible.
For reference, here is how a proposal would be assessed:
┌─────────────────────────────────────────────────────────────────┐
│ FEASIBILITY ASSESSMENT │
├─────────────────────────────────────────────────────────────────┤
│ Proposal: Add real-time collaborative editing │
├─────────────────────────────────────────────────────────────────┤
│ Base Rating: F4 (Severe) │
│ Risk Vectors: +1.5 │
│ [x] External dependencies (WebSocket library) │
│ [x] Public API changes │
│ [x] Previously attempted (2024, abandoned) │
│ Effective Rating: F5 (Catastrophic) │
│ Effort Band: XL (Months) │
├─────────────────────────────────────────────────────────────────┤
│ Failure Scenario: │
│ Partial implementation ships, causes data conflicts, │
│ requires emergency rollback, erodes user trust. │
├─────────────────────────────────────────────────────────────────┤
│ Recommendation: FULL COURT DELIBERATION REQUIRED │
│ Strong presumption against proceeding │
└─────────────────────────────────────────────────────────────────┘
The courtroom empties. The Scribe files the ruling. The Prophet's fractals are left on the table—they almost look like a system architecture diagram, if you squint.
The Judge remains, reviewing the framework one more time.
MORNINGSTAR:
to no one in particular
We have built a machine for saying "no" thoughtfully.
pause
That may be the best we can hope for.
exits
END OF DELIBERATION
Document preserved for institutional reference. May future courts find it useful, or at least amusing.